home *** CD-ROM | disk | FTP | other *** search
/ HPAVC / HPAVC CD-ROM.iso / CIS_GAME.ARJ / QWOLF1.THD < prev    next >
Text File  |  1993-07-01  |  11KB  |  229 lines
  1. -------------------------------------------------------------------------
  2.  this comes before WOLF3D.THD already in the library
  3. -------------------------------------------------------------------------
  4.  
  5. ______________________ Subj: How Wolfenstein 3-D Works ______________________
  6.  
  7. Fm: Mark Betz/GD SL 76605,2346                 # 172255 
  8. To: Ed. Mueller 70441,3720                     Date: 28-May-92  09:27:58
  9.  
  10. Hi, Ed. Since Id's techniques are there own property, and haven't been
  11. published, the best we can do is speculate. I asked Id during the conference
  12. if they were mapping to a rotated wireframe, and they replied that they were
  13. not, and that the engine was "image-based". That tells me that they are not
  14. using a 3D model of the castle, but rather faking it by scaling and
  15. foreshortening bitmaps before tiling them to the screen. One method that I've
  16. thought of would involve the use of a perspective template, a collection of
  17. lines of perspective that would allow you to decide the shape of a bitmap
  18. based on it's position and distance relative to the viewer.
  19.  
  20. As for how they got such good performance, I think there are a couple of
  21. aspects to it. One, they certainly wrote some highly optimized assembler.
  22. Two, there's not much going on in the background of the game, so they
  23. probably had a lot of cycles to devote to the animation.
  24.  
  25. The thing that really caught my interest at the CO was the statement that
  26. this technology was "way surpassed" already.
  27.  
  28.                                                        --Mark
  29. ...........................................................................
  30.  
  31. Fm: Karl R Corritore 70243,1110                # 172580 
  32. To: Karl R Corritore 70243,1110 (X)            Date: 29-May-92  13:26:24
  33.  
  34. Now that I got the game, I can tell you what I DO know about how they do the
  35. screens. They have 3 different pages that they switch between for the
  36. animation, to make it smoother.. They have 1 page which has a lot of
  37. different groups of colors..these look like what they use to put the 'bad
  38. guys' together,possibly 4 pixels at a time.
  39.         As they show you one screen, they write to a hidden page by first
  40. writing, 4 pixels at a time, the top and bottom sections of the screen( the
  41. ceiling and the floor), which meet at the middle of the page.(Therefore
  42. making 2 solid color sections) Then they write the walls and stuff going
  43. downwards, not left to right, because this way lessens the amount of times
  44. you have to do OUT's to the ports(I use this for my own animation). The
  45. lights and the spots in the floor are put in next, I guess. Then the 'bad
  46. guys' are put in last..I could not tell you how they figure out the walls in
  47. 3d though. 
  48.         _Karl
  49. ...........................................................................
  50.   
  51. Fm: guardian 76307,1643                        # 315446 
  52. To: Christopher P. Kucsera 71303,3441 (X)      Date: 17-Mar-93  14:16:48
  53.  
  54. Chris:
  55. I'm almost exactly where you are, with the SAME questions!  This is not much
  56. help, but here's the little bit that I know...
  57.  
  58. A) There are several types of "objects" used in Wolf3D, and it helps to think
  59. of them in the following types:
  60. - wall objects, which are actually geometric cubes with graphics displayed on
  61. them - impassable
  62. -"actor" objects, displayed as a flat "billboard" on the playing field,
  63. always perpendicular to your P.O.V., and graphics determined by some type of
  64. direction variable.
  65. -"object" object, displayed as a flat billboard same as the actors, sometimes
  66. passable, sometimes not.
  67. -goodie object, passable, disappears on contact
  68. -door object, displays parallel to direction picked, moves graphic "door"
  69. when activated
  70.  
  71. You get the idea.  If you don't yet have Bill Kirby's Map Editor, get it.  It
  72. will help you think of the game in terms of these objects.
  73.  
  74. B) Check out a book called POWER GRAPHICS IN TURBO C++, available at Barnes &
  75. Noble bookstores.  I plan to buy it when I can afford it ($24.95), as it
  76. covers things like handling PCXs & GIFs in Turbo C++ code.
  77.  
  78. C) Check out in these libraries a game called KEN'S LABYRINTH.  It is a
  79. decent WOLF clone written by a high school age guy.  The code can't be THAT
  80. hard if he could write it! (By the way, he has sold the game to Epic
  81. Megagames  
  82. ...........................................................................
  83.  
  84. Fm: Jaimi McEntire 71700,1202                  # 315758 
  85. To: guardian 76307,1643 (X)                    Date: 17-Mar-93  21:58:25
  86.  
  87. I talked to the guy who wrote Kens labyrinth, and he claimed to have done it
  88. with a 2-d type of ray tracing routine - i.e. scanning out from your point of
  89. view for each line until you hit an object, determining its distance, and
  90. then drawing that particular vertical line. the distance from the object that
  91. you hit is proportional to the size of the line.  you do this for each
  92. vertical line in your window. All in all not too wierd if you just think of
  93. it backwards.
  94.  
  95. Jaimi
  96. ...........................................................................
  97.  
  98. Fm: KGliner 70363,3672                         # 315839 
  99. To: Jaimi McEntire 71700,1202 (X)              Date: 18-Mar-93  02:11:10
  100.  
  101. Jaimi-- I never understood how the raytrace method could be made to work fast
  102. enough.  It just seemed like there were too many calculations to be done.  I
  103. mean, scanning out from the point of view until you hit an object must be
  104. slow, no?  Maybe if you have the images fixed at 90 degree angles like Wolf3d
  105. and Lab3d it would be easier...
  106.  
  107.    Well, if that's the approach used by Ken Silverman, he obviously got it to
  108. run quick enough.  Not that it's the only way to do 3d (I use an object based
  109. method), but I'd still be very curious to hear more specifically how he did
  110. it...
  111.  
  112.  
  113.   Kevin
  114. ...........................................................................
  115.  
  116. Fm: KGliner 70363,3672                         # 315838 
  117. To: Bruce Nehlsen 76535,2466 (X)               Date: 18-Mar-93  02:11:05
  118.  
  119.   One thing that can help is to do all your bitmap scalings/renderings/
  120. whatever to a buffer in ram and then just blitting the buffer when you're
  121. through.
  122.  
  123.   Kevin
  124. ...........................................................................
  125.  
  126. Fm: Jaimi McEntire 71700,1202                  # 316047 
  127. To: Bruce Nehlsen 76535,2466 (X)               Date: 18-Mar-93  13:43:20
  128.  
  129. You could scal to an off screen buffer and then transfer each bitplane at one
  130. time. that would only mean 4 plane changes, and increase the speed
  131. considerably.
  132.  
  133. Jaimi
  134.  
  135. -------------------------------------------------------------------------
  136.  this covers the thread break in WOLF3D.THD
  137. -------------------------------------------------------------------------
  138.  
  139. __________________________ Subj: How Wolf3D Works __________________________
  140.  
  141. Fm: Epic MegaGames 70451,633                   # 320015 
  142. To: KGliner 70363,3672                         Date: 24-Mar-93  22:46:12
  143.  
  144. Kevin,  the purpose of raycasting is to figure out,  for each vertical column
  145. of pixels,  the exact location where the ray intersects with a wall tile. 
  146. Once you find this out,  you draw a vertical column of pixels from the wall's
  147. bitmap. 
  148.  
  149. I guess this really isn't a very explainable technique.  So,  sit down with
  150. Wolfenstein for a few hours and look at exactly how the screen appears,  and
  151. the concept will sort of burn itself into your brain.  :-)
  152.  
  153. Same with the Doom screen shots.  The incredible thing about Doom is the
  154. light sourcing that's apparent in the screens.  That's not a difficult thing
  155. to do, but I can't imagine coding it to run at even one frame per second on a
  156. 486/50, cause the calculations are massive.  There's a sheer genius over
  157. there at Id Software.  I can't wait to play that game!
  158.  
  159. Tim
  160. ...........................................................................
  161.  
  162. Fm: Bruce Nehlsen 76535,2466                   # 319193 
  163. To: Epic MegaGames 70451,633 (X)               Date: 23-Mar-93  19:01:26
  164.  
  165. Tim -
  166.  
  167. Thanks, I'm getting the concept.
  168.  
  169. Next Question: What is a workable structure for representing the levels of a
  170. 3D building interior (like in Wolf3D)?  I've started using "blocks", each of
  171. which is a position block which has links to any adjacent existing blocks.
  172.  
  173. This is OK, but now iterating through the links to see what to draw is a big,
  174. leafy mess.  I followed your note on raycasting; how would the floor be laid
  175. out with that method of rendering?
  176.  
  177. Once again, thanks, from me and many lurkers.
  178. ...........................................................................
  179.  
  180. Fm: Epic MegaGames 70451,633                   # 320017 
  181. To: Bruce Nehlsen 76535,2466                   Date: 24-Mar-93  22:46:16
  182.  
  183. No, no, no,  don't worry about links or anything like that.  Wolfenstein 3D
  184. is a simple 2D tile map.
  185.  
  186. Here is all the ingenuity that goes into storing a Wolfenstein level:
  187.  
  188. #define numtiles 255 #define tile_x_size 64 #define tile_y_size 64 #define
  189. level_x_size 64 #define level_y_size 64
  190.  
  191. unsigned char WolfLevel[level_x_size][level_y_size]; unsigned char
  192. TileBitMaps[numtiles][tile_x_size][tile_y_size];
  193.  
  194. That's all.  Wolf3D,  Doom,  and Comanche Maximum Overkill are all entirely
  195. TWO-DIMENSIONAL GAMES which draw the screen in such a clever way that it
  196. looks 3D.  The 3D appearance comes entirely from the routine which draws the
  197. screen. All internal data structures are entirely 2D!
  198.  
  199. Tim
  200. ...........................................................................
  201.  
  202. Fm: KGliner 70363,3672                         # 320083 
  203. To: Epic MegaGames 70451,633 (X)               Date: 25-Mar-93  00:54:30
  204.  
  205. Tim--  What I was trying to get at was how many calculations have to be done
  206. for each vertical line on the screen (ie. find the intersection with the wall
  207. tile, find which vertical line in the bitmap for that wall to draw, deal with
  208. any clipping, etc.).  I guess it just doesn't strike me as being much faster
  209. than an object-based approach (which is what I have used to a high degree of
  210. success).
  211.  
  212.    Btw-  do you happen to know the frame rates for Wolf3d on some of the low
  213. end machines (like 386sx16 or 386dx16)?  Or how about Lab3d, since you are
  214. distributing that now.
  215.  
  216.    Light sourcing isn't that hard...all it amounts to is 1 additional asm
  217. instruction in the inner loop of the vertical line drawing routine (and some
  218. setup code earlier in the program).  In my version that would amount to no
  219. more than a 10% reduction in speed (although in my game it would look kinda
  220. funny to have all the walls light sourced but the floor and ceiling still a
  221. single solid color).  I imagine it would have even less impact on any sort of
  222. floor texture mapping because those have more instructions at their core.
  223.  
  224.  
  225.    Kevin
  226. ...........................................................................
  227.  
  228.  
  229.